在 「Notion 遇上 LLM：30 天打造我的 AI 知識管理系統」 系列中，經過 Day 1 的動機與 Day 2 的藍圖設計後，今天我們要回到根基 —— Notion API。理解它是怎麼設計的，能取得什麼資料，以及授權流程，這些都是後續開發的基礎。

Notion API 是什麼？

Notion 官方提供了一個 Public REST API，讓開發者能透過程式操作 Notion 工作區的元素，包括頁面 (Pages)、資料庫 (Databases)、使用者 (Users) 與評論 (Comments)。
它並不是嚴格的「RESTful API」，但提供了完整的 HTTP 方法：

• GET：讀取頁面或資料庫內容
• POST：新增資料庫條目
• PATCH：更新屬性

對我們來說，這樣的設計已經足以支援自動化、清理與檢索的需求。

Notion API 能做什麼？

以下整理了 API 的主要功能，以及在本系列專案中的用途：

在這個 30 天專案裡，我會特別聚焦於 Pages、Databases、Search 這三大能力，因為它們最直接影響知識檢索與生成，是讓 Notion 筆記「動起來」的核心基礎。

Integration：Bot 的角色

要讓 API 運作，必須先建立一個 Integration，而這個 Integration 本質上就是一個「Bot 使用者」:

• 它帶著 API Token，替你存取頁面或資料庫。
• 權限完全由你指定，例如只允許讀取某個資料庫，或同時支援讀／寫。

這也是第一個容易踩坑的地方：光有 Token 還不夠，還需要在 Notion 裡把 Integration 加進工作區，並手動授權它存取特定頁面或資料庫，否則 API 呼叫會失敗。

Internal vs. Public Integration：要選哪一種？

Notion 的 Integration 分成兩種：

對於本系列來說，Internal Integration 已足夠。因為目標是打造個人化的知識助理，不需要跨多人或公開發佈，這樣能簡化流程，也比較安全。

API 的潛在應用場景

即使不結合 AI，光靠 Notion API 其實就能解決很多需求：

• 自動化通知：當資料庫有變更時，觸發 Slack / Teams 通知。
• 跨系統整合：讓 GitHub Issue ↔ Notion Database 雙向同步。
• 外部資料導入：自動將新聞或研究文章匯入 Notion，建立統一知識入口。

這些案例都顯示了 Notion API 的彈性，而在本系列中，我會進一步把它與 LLM + RAG Pipeline 結合，讓筆記從「儲存」變成「會說話的知識庫」。

小結與下篇預告

今天，我們理解了 Notion API 的定位與功能，知道了如何透過 Integration 建立一個 Bot 來讀寫資料，也釐清了 Internal 與 Public Integration 的差異。它是本系列裡的「第一扇門」，未來所有的清理、切片、檢索與生成都要從這裡開始。

在 Day 4，我們會動手實作：串接 API 抓取資料。我會用 Python 範例程式碼，展示如何透過 API Token 把筆記內容取出來，轉成 JSON，這將是知識循環的第一步。

參考資料

• Notion 官方開發者平台
• Getting Started 指南
• API Reference